为什么说“大公司的技术顽疾根本挽救不了”？

查看原文

其他

为什么说“大公司的技术顽疾根本挽救不了”？

Lawrence Krubner CSDN 2019-07-10

【CSDN 编者按】在很多开发者看来，提升敏捷性是解决技术难题的不二法则。但本文的作者作为一家有着一百多年历史的大公司的技术援助顾问却认为，由于历史遗留、文化隔阂等原因决定：在大公司，所谓的敏捷性开发其实并不是人们以为的管用。

为什么他会这么说呢？一起来看看。

作者 | Lawrence Krubner

译者 | 苏本如，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

以下为译文：

在硅谷流传着很多油嘴滑舌、哗众取宠的肤浅言论，这些言论都是关于开发过程中保持敏捷的重要性的。关于引入敏捷技术的容易性，以及哪些问题可以通过敏捷技术解决，有太多的假设。在这篇文章中，我试图纠正其中的一些错误看法。

在过去的20年里，我曾经是三家初创公司的技术合伙创始人，其中两家公司发展到中等规模后被卖掉了，后来我给一些中型到大型规模的公司做一些咨询工作。这些公司通常有几个办公室，最多可能有3000人。特别是我在2009年搬到纽约后，我成了一名技术救援人员，试图帮助拯救那些技术落后于时代的老媒体公司，让他们迎头赶上新技术。

现在我正在为我曾经合作过的最大的集团公司工作。它拥有11000名员工，旗下有180家公司在运营。这是一家你们大多数人可能都认识的著名公司，你们中的许多人可能还是它的客户。在本文中，我将它称为“SuperRentalCorp”。

关于“初创企业很敏捷，而大公司就像转个身都困难的恐龙一样难以成事”这一主题的文章，已经比比皆是。许多商业作家甚至写了一些有趣的书，来介绍大公司如何重组以使其更加敏捷。例如，埃里克·里斯在他的书《创业之路》中提出过一些有趣的想法。

但拯救一家大公司的技术是如此困难，原因何在呢？

在SuperRentalCorp发生的一些问题就是一个很好的例子。

当我最初被告知这家公司需要帮助时，是这样的情形。我的一个给这家公司做咨询工作的朋友这样对我说：“嘿，这家公司需要帮助构建一个API。你知道如何构建API吗？你能帮他们吗？”他告诉我，这家公司尝试构建这个API已经两年了，但到目前为止他们还在失败。

我心里想，“用两年的时间来构建一个API，并且还失败了！看在上帝的份上，现在都已经是2019年了，有几百万个工具可以用来轻松构建API。他们怎么可能认为这很困难呢？一个好的工程师可以在一天内把这件事解决掉。他们为什么苦苦挣扎这么久？”

但是我最初的想法是基于这样的一种场景假设：你只有一个数据库，而你想要做的只是将API置于你的数据库和外部世界之间。这是我在早期初创公司工作时的常见场景。如果使用一个新建的Ruby on Rails项目，说正经的，你可以在一个小时内构建出这种API。

然而，对大公司来讲，有两个大问题困扰着大公司的技术救援：历史和信任。

——我先谈谈历史。

当我提到“历史”这个词时，我指的不是简单地解决历史遗留应用程序的问题，而是处理过去30或40年间不同CEO所做决定的遗留后果，因为公司对过去每个十年时代的变化趋势都得适应。

SuperRentalCorp成立于100多年前，当时世界大部分地区由几个欧洲帝国统治，而大多数公司都是依托他们在西方国家内的公司来经营全球业务。但在1948年至1980年的那个时代，所有的旧帝国都解体了，取而代之的是一百多个新的国家，而这些新国家都保护着自己的独立性。因此，SuperRentalCorp决定采用分散结构。它在大多数国家中设立了子公司，并且子公司作为独立公司运营。有时子公司的部分所有权被出售给他人。这意味着，当上世纪70年代末第一批大型数据库来到时，这家公司没有中央数据库、中央IT部门、也没有首席技术官或首席信息官。

不久之后，由于政治形势似乎变得安全了一些，合并一些服务的好处变得显而易见，因此一些子公司被合并，组建了区域性公司。例如，中东和北非有一家，欧洲有一家，北美有一家，亚洲有一家，南美有一家。通过这种结构，这家公司进入了90年代，这时它开始认真考虑通过网络数据库来管理它所提供的所有服务。

20世纪90年代，面对激烈的全球竞争，这家公司决定通过收购最成功的竞争对手们来实现增长。如果我告诉这些被收购的所有的品牌名字，你会认出其中的大多数，但你可能会惊讶地发现他们现在都为一家公司所拥有。我也很惊讶，因为我也认为这些公司是竞争对手。但事实上他们不再是了。

然后，大约在2005年Web2.0时代的到来，导致竞争对手大量涌现，这些竞争对手提供类似于SuperRentalCorp的服务，但是他们通过使用互联网技术，以新的方式来提供这些服务。同样地，SuperRentalCorp收购了其中的几家初创公司，通过吸收竞争对手来赢得竞争的胜利。许多被收购的初创公司只在单一国家，或单一的市场（如欧盟）内运营。

就在最近，这家公司的新首席执行官决定最好把公司统一起来。一些国际子公司已被全资收购，目前正在进行重组，因此它们将作为公司内部的部门而非独立公司运营。

作为对公司统一的新的重点工作的一部分，SuperRentalCorp希望构建一个统一的API，以便外界认为该公司具有内部统一的技术架构。也就是说，SuperRentalCorp希望给外界一个这样的假象：即该公司只有一个统一的数据库，并且与该数据库的交互很容易。

然而，真实的情况是怎样呢？真实的情况是：SuperRentalCorp拥有20个主要数据库，由20个不同的团队在至少10个不同的国家/地区运行，其中许多拥有独立公司的运营历史，每个团队都保护自己的数据，部分出于安全担忧，部分出于对有关用户隐私的本地法律和对国际用户数据传输的监管的担忧，还有部分原因是纯粹的顽固。

和任何数据库的操作一样，这里有两个需要关注的问题：读取和写入。数据库读取并不难。我们可以从20个不同的数据库中提取（必要的）数据，将数据存储在一个作为缓存的集中数据库中，并在该数据库和外部世界之间放置一个API。数据的时效会出现一些小问题，我们必须进行实验，以确定哪些数据是高优先级的，需要在几秒钟内复制过来。不太重要的数据可以每5分钟复制一次，或者在更新时触发一次复制操作。

所以，数据库读取不是那么困难，虽然不简单，但总是有办法做到。

数据库写入操作则是另一回事了。如果伦敦的一个客户想从我们在伦敦的子公司租用一个资源，租用请求（数据库写入）需要转到中央API，这是否意味着中心API必须知道特定的写入操作应该转到哪个内部数据库？同样，写入请求也发生在尼日利亚、德国和巴西，每个国家的写入请求都将进入各自的数据库。这就变成了一场噩梦——二十年前，这种思路导致了企业服务总线（ESB）体系结构的创建，但是ESB现在已经不受欢迎了，因为它过于复杂、僵硬和笨拙。

两年前，SuperRentalCorp决定成为MuleSoft公司的客户，以便MuleSoft公司帮助他们构建新的API。到目前为止，他们已经投资了大约2500万美元在MuleSoft公司所做的相关工作上。MuleSoft公司有一些很好的工具来构建API，但是这些工具似乎对数据读取比对数据写入更有帮助。也就是说，MuleSoft公司的工具对简单的问题有帮助，但对困难的问题却没有效果。（既然说了这句话，我还想再补充一句，SuperRentalCorp里有一些，他们超爱MuleSoft。）

从最佳集成架构的角度而言，我认为唯一可以作为长期解决方案的是类似于Jay Kreps在2013年前后写的统一日志架构。这个架构中，所有的写入操作都需要进入一个集中的日志，例如Kafka，然后各个数据库就可以从那里提取他们需要的内容，每个团队都要自己决定从集中的日志提取的内容。

但是，SuperRentalCorp有一些零售店，配有直接与特定的数据库进行通信的POS系统，对这些零售店而言，数据写入的路径（直接从POS到数据库）是以难以更改的方式硬编码的，因此想要拥有一个单一的写入点，SuperRentalCorp还需要花费几年的时间。

目前，SuperRentalCorp的每个数据库团队都必须接受来自多个源的写入操作。但从长远来看，统一的日志是一条可行之路。这意味着这20个团队中的每一个团队都必须对他们的流程做出重大的改变。这就解释了为什么该公司花费了2年时间，投资了2500万美元试图构建一个API，最终却失败了的这一事实。

这个问题的发生部分是技术性的，部分是心理性的。每个团队必须放弃一些权力，然后信任一个超出他们控制的流程。当公司有一个新的首席执行官时会发生什么？如果他决定再次拆分公司呢？团队对当前公司战略的持久性有多信任？他们是不是应该给自己留点空间，回到过去做事的方式？......

到目前为止，我只讨论了由内部数据库和内部流程引起的问题。从某种意义上说，与依赖那些外部供应商提供的超出了SuperRentalCorp的控制的服务相比，内部机制导致的问题都是容易解决的。

从20世纪90年代开始，出现了一种管理理念，认为公司应该专注于其“核心竞争力”，并将其它一切外包出去。比如说，如果你是一家报纸，你不需要雇佣清洁工来保持办公室的清洁，而是应该把清洁工作外包给一家专门从事清洁公司办公室的公司。把精力集中在你擅长的事情上，把其它的一切交给别人去做。如果你试图自己做每件事，那么你就犯了“非自主发明综合症”。尽管我已经看到了不利的一面，但在这场争论中，有很多是我同意的。外包限制了你的灵活性，因为你最终与外部公司建立了长期关系，但这些公司可能并不会随着你的需求的变化而发展。虽然解雇一家清洁服务公司并雇佣另一家似乎很容易，但有些服务公司却很难更换。

早在20世纪90年代，SuperRentalCorp就决定将其客户忠诚度计划的管理外包，因为它被视为一项财务职能，而SuperRentalCorp不是一家财务公司。他们挑选的外包公司也非常原始落后，甚至不为其服务提供公共的API。因此，现在当SuperRentalCorp希望将其忠诚度管理系统集成到各种CRM（客户关系管理）系统和POS系统中时，它无法做到这一点，因为SuperRentalCorp对管理其忠诚度计划的外包公司的技术决策没有决定权。是的，SuperRentalCorp可以终止与这家外包公司的业务关系，开发自己的系统来管理忠诚度计划，但他们已经正在处理大量其它的技术难题。而目前，终止与管理其忠诚度计划的外包公司的业务关系还不能作为一种选项。

所有这些都有助于解释为什么一家大而老的公司的技术救援是如此困难，因为它不得不持续地和它的历史作斗争。

困扰着大公司技术救援的还有另外一个问题，那就是信任。拥有庞大资产的公司每天都要与内部和外部的不诚实的行为者打交道，这不是危言耸听，而是日常的现实。关于公司应该如何变得更敏捷的华而不实的肤浅言辞并不是很有帮助，因为公司需要面对的是公司结构、所有权和战略等真正的问题。尽管我很喜欢初创者社区，但是我觉得来自硅谷的太多文章描述的大公司和老公司所面临的问题只是简单的假设。特别是，大部分文章都认为信任问题是庸人自扰，而并认为是重要的和真实存在的。一些肤浅的建议倾向于“假定善意”，就好像数十亿美元的公司就像维基百科一样。

事实上，大公司一直面临着被公司内外的贪婪所摧毁的风险。而初创企业在处理信任问题上比较容易，因为当整个团队只有5个人时，你们都可以直视对方的眼睛，当他们表现异常时，你可以再次检查你的同事。而当你在180个国家拥有11000名员工时，这是不可能做到的。

在很大程度上，“敏捷”几乎等同于“互相信任”。如果你想知道为什么大公司在敏捷方面有困难，部分原因是11000人不可能像5个人那样互相信任。现实就是这样，除非有人能想出一个神奇的法术，让不同国家、不同文化、讲不同语言的大批人彼此信任，就像他们是好朋友一样，如果真能这样的话，那么初创社区的人们需要注意了，可以看出这些建议是多么地不走心。

原文：http://www.smashcompany.com/business/why-are-large-companies-so-difficult-to-rescue-regarding-bad-internal-technology

本文为 CSDN 翻译，转载请注明来源出处。

【END】

精彩课程推荐

主题：智能文本信息抽取算法的进阶与应用

课程大纲

1.文本挖掘简介和抽取算法概况

2.传统抽取算法原理及案例：HMM、CRF（重点）

3.基于深度学习的抽取算法原理及案例：双向LSTM、预训练模型（重点）

4.抽取算法在达观数据的应用实践

5.进阶资源推荐

扫描下方二维码，免费报名。